\subsection{Comparação com WJDBC}
\label{sec:diswjdbccmp}

%CJDBC_I
No geral a solução ${\bf CJDBC_I}$ tem um desempenho inferior ao demonstrado pela solução $WJDBC$.

Também na generalidade, para quantidades de threads maiores a solução $CJDBC_I$ perde desempenho em relação a $WJDBC$. 
Embora a solução $CJDBC_I$ seja menos restritivo em relação ao \gls{lock} e permita que mais código seja executado concorrentemente, a solução é mais pesada quanto à utilização de recursos do lado do cliente. 
A solução $WJDBC$ partilha o mesmo objecto result set utilizando cursores cujo peso é insignificante. 
Um cursor no $WJDBC$ não é muito mais do que uma classe que possui uma referência para um ResultSet e um inteiro que guarda a linha actual do result set. 
Já a solução $CJDBC_I$ constrói um cache por cursor.
Com a excepção da alocação de um cursor do servidor, isso é semelhante ao $MSJDBC$ em que se constrói $n$ result sets para $n$ threads. 
À medida em que a quantidade de threads aumenta é cada vez mais penoso criar um cache para cada cursor de cada thread, o que se reflete numa perda de desempenho. 
É na Leitura que se nota mais o peso de criar os vários caches.

A situação onde existe mais equilíbrio é na inserção, existindo até uma ligeira vantagem para $CJDBC_I$ que ronda os 2 a 6\% para quantidades de threads maiores. 
Na inserção a interacção com o servidor é mínima, não existe o \gls{fetch} do result set, apenas são inseridos dados do cliente no servidor. 
O que se verifica no $WJDBC$ para quantidades de threads maiores é que existe menos código concorrente a ser executado, pois a solução $WJDBC$ bloqueia o acesso ao objecto result set quando inicia o processo de inserção. 
Daí surgir a vantagem para o $CJDBC_I$.

\hfill \\

%CJDBC_S
A solução ${\bf CJDBC_S}$ e a $WJDBC$ em geral têm um desempenho semelhante, o que até era espectável pois o princípio de funcionamento de ambos é o mesmo: existe um objecto utilizado para operar sobre o \gls{dataset} e que é partilhado pelos threads. 

A diferença encontra-se no local onde é realizado o acesso exclusivo ao objecto partilhado: num nível mais alto para o $WJDBC$, e num nível mais baixo para o $CJDBC_S$.
Obtendo o \gls{lock} num nível mais alto não há tanta sensibilidade para o distinguir o código que é concorrente do que não é concorrente; todo o código executado depois do lock é executado não concorrentemente, e por isso pode acontecer estar-se a diminuir o desempenho.
Obtendo o lock num nível mais baixo há a possibilidade de se identificarem as zonas do código que têm de ser executadas com acesso exclusivo e que não podem ser executadas concorrentemente (zona crítica), efectuando apenas o lock nessas zonas existe mais código concorrente.
E com mais código concorrente obtemos um aumento de desempenho.

Apesar da proximidade de desempenho de ambas as soluções, nota-se uma vantagem em favor da solução $CJDBC_S$.
E é no contexto da Leitura que se verifica uma clara superioridade de $CJDBC_S$ em relação a $WJDBC$.
A razão está relacionada com o nível mais baixo de implementação dos locks e com a construção especial desta solução, em que se sabe que o cache tem todas as linhas do dataset, e por isso comunica menos com o servidor, aumentando o desempenho.

O tempo de preparação do $CJDBC_S$ é mais alto porque esta solução cria o cache partilhado na instanciação, e o $WJDBC$ só pede as linhas do dataset quando precisa delas, ou seja, em execução (o que também reduz o desempenho de $WJDBC$ na execução, principalmente no contexto da Leitura).
